Present technology allows mobile devices operating on wireless networks to access information stored on a separate, wired network, such as the Internet. FIG. 1 illustrates an example of a network environment in which this may be done. A number (N) of mobile devices 1—1 through 1−N operate on a wireless network 2. Each of the mobile devices 1 may be, for example, any one of a cellular telephone, personal digital assistant (PDA), notebook (laptop) computer, two-way pager, or other wireless device. The wireless network 2 is coupled to a conventional wired computer network 3 through a proxy gateway 4. The wired network 3 may be, for example, the Internet, a corporate intranet, a wide area network (WAN), a local area network (LAN), a public switched telephone network (PSTN), or a combination thereof.
The proxy gateway 4 uses well-known techniques to enable communication between the mobile devices 1 and a number (M) of processing systems 5-1 through 5-M operating on the wired network 3. The physical computing platforms which embody the proxy gateway 4 and processing systems 5 may include, for example, conventional personal computers (PCs) and/or server-class computer systems. Among other operations, the proxy gateway 4 may convert/translate between the languages and protocols used by processing systems 5, such as hypertext markup Language (HTML) and hypertext transport protocol (HTTP), and the languages and protocols used by the mobile devices 1, such as wireless markup language (WML) and wireless access protocol (WAP). Accordingly, in one embodiment the proxy gateway 4 operates as a proxy for transmitting various requests on behalf of the mobile devices 1 and the processing devices 5, as described further below. An example of a device which can serve as the proxy gateway 4 is the UP.Link Server, from Openwave Systems of Redwood City, Calif. Note that while proxy gateway 4 is shown as a single entity, the proxy and gateway functions can be distributed between separate physical platforms. Furthermore, both functions do not necessarily have to be used in a given network environment.
Processing systems 5 include one or more “origin servers” (e.g., 5-1) and one or more “service initiators” (e.g., 5-M). Origin servers provide content, such as hypermedia documents, to mobile devices 1 in response to standard (e.g., HTTP) requests from the mobile devices 1. Service initiators “push” content to the mobile devices 1, i.e., they send content to the mobile devices 1 without the content having been explicitly requested by the mobile devices 1. Note that an origin server and a service initiator may be implemented within the same computing platform and are often implemented within a single network domain.
One problem associated with a network environment such as this is that data identifying each of the mobile devices 1 is commonly distributed to many other processing systems, such as processing systems 5 on the wired network 3. This identification data can be used for a variety of purposes, some of which are undesirable for the users of the mobile devices.
When a mobile device (a “client”) makes a request for content via the proxy gateway 4, the proxy gateway 4 may add identification data to the meta-data (e.g., HTTP request headers) of that request, which is passed on to the origin server 5, as shown in FIG. 2A. This scenario is referred to as the “pull” scenario. The identification data may be a direct reference to the source address of the client (e.g., the client's mobile telephone number in the case of wireless access), or it may be the identity of the client as determined from the provisioning system controlling the proxy. The rules governing the addition of this identification data are normally controlled by a “white list” within the proxy gateway 4. The white list is a list of domain name references to which service is permitted. The client identity data may also be used as a rendezvous address for services making requests to the client, such as WAP push requests.
The client identity information may be used in a number of legitimate ways, such as: to allow devices responding to requests to authenticate the requesting mobile devices; to track the devices' requests and develop client profiles on an origin server; to tailor a response to the request and to the identity of the client; to allow access for services that make subsequent requests to the client, such as the “Posting” of documents or WAP push requests; or, to allow the client to be accessed by another communication medium, such as a short message service (SMS) message or a telephone call. Thus, the client identity passed as part of a pull request may be subsequently used in a push scenario to gain access to the client via a service proxy or gateway.
The problem is that the same identity is normally given to all servers, regardless of the intended use of the service. As a result, the client is made vulnerable in several ways. For example, disclosure of the client identity allows unsolicited access to be made to the client, such as in the form of phone calls, SMS messages, or WAP push requests, without prior authorization being given for those services. This situation is illustrated in FIG. 2B, in which a request from a service initiator 5 includes the client identity previously acquired from the proxy gateway 4, which is used to gain access to the mobile device 1. In addition, client preferences may be gathered by groups of unrelated servers using the identity supplied by the proxy gateway. Furthermore, the client identity may not be changed for an individual proxy. Once established for a single server, the client identity is valid for all servers. Consequently, it is difficult to control misuse on an individual service provider basis without assigning a new identity to the client (which may be impossible or impractical).
One attempt at solving this privacy problem is the use of pseudonyms. The pseudonym approach works by encrypting the client information at the source. However, this technique does not account for cases in which client identity information is added by network elements along the path of the request. In addition, only a single pseudonym is in operation at any one time, such that a client identity cannot be encrypted on a per-URI (uniform resource identifier) basis. In addition, the pseudonym technique is not designed to regulate any form of push service.
Another partial solution to the privacy problem is known as Platform for Privacy Preferences Project (P3P). According to this approach, a P3P client negotiates the release of personal data with the origin server prior to completing a request. The privacy policy acceptable to the client and the privacy policy of the server are both expressed in schema defined by the P3P group within the World Wide Web Consortium (W3C). This approach, however, does not prevent a client's identity from being communicated to an origin server. In addition, as with pseudonyms, there is no way to regulate a service which may initiate a request toward the client.
What is needed, therefore, is a solution which overcomes these and other shortcomings of the prior art.